


Workflow from Google Docs to Ao3: A Primer

by Jenrose



Category: Archive of Our Own, Google Docs - Fandom
Genre: Destroying the extra paragraph breaks, Gen, How-to, Killing the italics space bug, Meta, Minimizing effort through smart setup, When styles get hairy, Workflow, Working with beta readers in Google Docs
Language: English
Status: Completed
Published: 2016-05-27
Updated: 2017-10-25
Packaged: 2018-07-10 10:45:24
Rating: General Audiences
Warnings: No Archive Warnings Apply
Chapters: 2
Words: 5,445
Publisher: archiveofourown.org
Story URL: https://archiveofourown.org/works/6981169
Author URL: https://archiveofourown.org/users/Jenrose/pseuds/Jenrose
Summary: <blockquote class="userstuff">
              <p>Google docs is fantastic for collaborative work, especially for people who work with beta readers. But getting from there to here can be tricky. Abundant screenshots.</p>
            </blockquote>





	1. Chapter 1

**Author's Note:**

> Thanks to Aergie and two family members for helping me with enough collaboration to get the screen shots. :)
> 
> You can read this in Google Docs too, but it looks better here.  
> https://docs.google.com/document/d/1WdzRb7ZxA6t5J2i-LBamnVS3aO8zIbilE1uXU1gq5M0/edit?usp=sharing

# Writing Workflows

## Setting up a Google Doc for optimal AO3 import

To use this most efficiently, open up a Google Doc and paste over a few lines of text, and then start experimenting as you read down.

  * Bolding a section heading will create outline entries along the side once you turn on Document Outline (tools menu).



 

 

This is handy for longer documents where you are writing multiple chapters in one document, or in tutorials such as this one where you want people in Google Docs to be able to skip to a relevant section quickly. If this does _not_ work, because your sections are short, and Google Docs decides it’s not a worthy entry, you can use styles to make it happen.

  * Highlight a bolded section heading, and go to “normal text” and pull it down and highlight “Header 3” and pick “Update header to match” so that you don’t change your section header/chapter title appearance, and then highlight everything you want to appear in the outline and pick “Header 3”. You can use multiple styles if you want to do an actual document outline that is more complex than chapter titles.



 

Note that if you use “Heading 2” for chapters and “Heading 3 for subheads, you’ll get a more sophisticated outline while you're writing. This isn't ideal for AO3 though. Chapter 2 explains how to get all the styles you need for AO3 in every doc.

Handy trick: If you are doing a prologue, use Heading 3 for the Prologue and Chapter 1 and put them both in the same "Chapter 1" in Ao3. Use heading 4 for subheads in that case. Heading 3 is similar to the chapter headlines and will make your story look mostly seamless in "entire work" view.

###  **Line Spacing**

  * Put in a few paragraph breaks when you start your document, then hit CTRL-A to select all text in your document.



 

  * Go to “Line Spacing” which may be under the “More” button, and pick “Add Space after paragraph.”



 

This will allow you to type with a visual break between paragraphs (much easier to read on screen) without hitting a double paragraph break. It will also make it obvious when you use a line break instead of a paragraph break. A line break happens when you hold down the shift key while you hit “Enter” instead of just hitting “Enter”.

Line breaks are useful for poetry and song lyrics, where you don’t want space between your paragraphs. They can import strangely in AO3, however, with inconsistent results depending on how they are used.

If you don’t adjust the line spacing, and instead use two paragraph breaks you will end up with very large gaps between every paragraph. This way, you get a tidy space that allows the eye to track nicely on the page, but without the huge gaps that make for a lot of scrolling.

In HMTL mode on AO3, you will see line breaks as <br> and paragraph breaks as <p>, although that gets a little dicy in the notes section.

Bonus: If you decide to print your document in alternative formats later, the optimal format for printing is _not_ the same as the optimal format for web. You’ll be able to make global changes to the text for better flow in e-reader documents and book layout.  You can, for example, edit your “normal text” to have no spaces after the paragraph and a first line indent, and be in Times New Roman, instead of Arial or Verdana, which is much more book-friendly, but is less than ideal on-screen.

###  **Automatic substitutions**

Google Docs has some handy tools that can make your writing more fluent. For example, you can tell it that every time you type two hyphens in a row, what you’re really after is an em-dash. So -- becomes —. This is _useful._

I also have three periods set up to replace with a true ellipsis. Thus, ... becomes … (Highlight them both to see the difference. The first is three periods. The true ellipsis is a single character.)

Pro tip: You can highlight each of these things, avoiding the spaces, and ctrl-c to copy, and then ctrl-v to paste them in your preferences. So you don’t have to go find an em dash in the special characters menu.

  * Go to “Tools” and pick “Preferences” to bring up the dialogue.



 

  * I will add things to this when I make the same typo more than once, as you can see.  (How many different ways can I misspell my character names? A lot, apparently.)



 

You can do shortcuts like this with whatever you like, so if you’re prone to using bullets in the middle of your text (not the shooty kind, but this kind •) then instead of digging it out of the special characters every time, you can set a preference that every time you type a double asterisk, like this: ** it should sub to • like so. Common switches include copyright, registration or trademark characters, with (c) becoming ©, for example.

  * To find your special characters in the first place, you can use the character map in Windows (just type charmap.exe in the start menu and it will pop up), you can find it with words on Google search (em dash, en dash, bullet character, copyright symbol will all get you what you need) or you can use the Google Docs special character menu on the "insert" menu.



 

  * The special character menu is huge. Enormous. Don't just poke around, type something like "bullet" and it will find what you want.



  * Click it once and it will drop into your text wherever your cursor was. Highlight it there, copy, and then bring up your preferences menu. Put the easy-to-type thing in the "replace" column and then paste your special character into the "With" column next to it. Don't forget to save your preferences! Zoom out if you can't see the button.



 

###  **The Dread Italics Import Bug**

So, you may have noticed that sometimes when you import into AO3, punctuation gets a little...weird around italicized text. Extra spaces show up. Spaces disappear. This seems to be related to where the italics tag sits in relation to the punctuation.

“ _The quotation mark is not italicized, and neither is the period_.”

 _“The quotation mark is italicized, and so is the period._ ” (But not the close quote)

 _“Everything is italicized.”_ <\--- This is the correct way to avoid extra spaces showing up around punctuation.

  * This picture is mostly because this whole thing is getting pasted back into Google Docs once all the images are in place. 



 

This can show up in a lot of places, but is particularly awkward around quote marks. Sometimes spaces disappear, too. This may be due to italicizing the space following the word, but usually only shows up in other workflows (Open Office and Fanfiction.net often have this issue, as well as copying text from HTML docs to repost things from other sites into AO3.) In general, _watch_ your spacing around italics. To minimize extra spaces, if your italicized word is up against punctuation, ALWAYS italicize the punctuation. If you look at both the AO3 version of this document and the Google Docs version of this document, you will see that in the above example, there are no extraneous spaces in the Google Doc, but there are in the top two italicized lines on AO3. (Look between the period and the quotation mark on the second example.)

  * Here's a screenshot of the original in Google Docs.



 

###  **Hunting Down Style Oddities**

You’ll see that in the last image of the Google document, “Heading 3” is simply bolded text. In AO3, “Heading 3” is a defined thing (“H3” in the html) that creates a very specific style with a double line below it. You can, if you choose, get around this by using “Heading 2” instead (no line, larger). But usually you’ll be posting a large section of text as a chapter and the chapter heading won’t be in there, but in the actual title, and it won’t matter. Only in documents like this does it really matter. You can use work skins to redefine styles or allow for other styles, but that’s beyond the scope of this section. See chapter 2 for more information on how to bend Google Docs to AO3's whim on style options.

###  **Scene Breaks—or—Where’s My Line**

Back in the bad old days of USENET, I used to use three asterisks.

***

Then I graduated to tildes.

~~~

Now, Google Docs has a horizontal line function.

It looks like this in Google Docs. 

 

Unfortunately it doesn’t (always? ever?) translate to AO3, as you can see by the fact that the only way to see what it looks like in Google Docs is to go back to the Google Doc or look at my screenshot. This was a surprise to me. It might have changed at some point recently? (Hence the text having changed after the screenshot was taken.)

But! AO3 does have a horizontal line function. Like this:

* * *

  * In the rich text editor (RTE) it’s just a button.



 

The fastest way I’ve found to deal with the missing scene break is to go back to the old fashioned method (~~~) and then in my browser, ctrl-F and each time I find that, I replace it with a horizontal line. By hand. This is fairly quick, looks good, and doesn’t completely leave you at sea for line breaks.

~~~  
This will be my marker for when I paste into the text importer. I don't bother centering until I'm in AO3.

Of course, you can use some cute emoticon, or whatever, and our “preferences” auto-replace dialogue can super duper help with this! In [Check, Please!](http://archiveofourown.org/tags/Check%20Please!%20\(Webcomic\)/works) for example, we might want our screen breaks to be crossed hockey sticks.

_X_ _X_ _X_

I would _not_ replace a single tilde (~) with a single hockey stick pair. I’d replace three in a row with three in a row, even though they’re different numbers of characters. Google Docs is honeybadger. It doesn’t care.

Why? Because if I'm writing in a different fandom, I might insert two tildes instead of three, to avoid the hockey sticks.

      

  * Keep in mind you may have to reassert the centering formatting in AO3, and it won’t automatically format centered in Google Docs, but both programs have a button for that. Looks the same in both places.  Above: Google docs (Don't bother, it won't import) Below: AO3 (Do use!)      



 

 

  * If you choose the emoticon option, you will only search for your emoticon and then center it, rather than replacing with a horizontal line.



 

 

## Working With a Beta Reader In Google Docs

Okay, so you’ve got a chunk of text and you want someone to proof it. This is _great._ A good beta reader is worth their weight in gold and will not only improve your story, but if you take advantage of their help, will improve your writing overall.

I find the most educational way to have a beta reader work is _not_ to have them edit the document directly.

  * Up in the corner, when you’re writing, there is a little “pencil” icon with the word “Editing next to it.” That’s ideal for you, the author.



 

But we want to know exactly what our beta reader is doing, and we want them to be _suggesting_ edits, not making final edits. Let me reiterate this… if you want to get the most out of your beta reader’s work, and get better as a writer, you will look at each and every edit they make and work at understanding why they’ve made it.

But first, let’s share.

###  **Sharing**

Okay, so we’ve got a couple options for sharing.

  * Click "Share".



 

  * Google Docs will make you title your document if you haven't already.



 

 

  * You can get your beta reader’s email and send it to them and them alone and pick “edit” from the drop down menu.



 

This will allow them to make changes in your document. But maybe you want to allow others to read and comment without making changes?

  * You can either add them and set their permissions one at a time, individually, or you can go to the advanced sharing options.



 

  * There, you can share more globally. I recommend against “Public” sharing. Usually “Anyone with the link” will be sufficient.



 

You can decide whether you want more casual beta readers to have editing ability, or just commenting ability.

  * First, click the "change" button here:



  

  * That will bring up this.



  * Change it to this if you want people to be able to comment in your document.



 

  * The link can be pasted into chat or email or whatever.



 

  * When they're actively looking at your document, you'll see this. Profile pics for people who are logged into the doc, and anon icons for people who've clicked through but not logged in. Note the tiny chat icon and the "Comments" button. More about those next.



 

###  **Editing vs. Suggesting vs. Commenting**

In general, I prefer to use suggestion mode for punctuation, spelling, and short word changes. Suggestion mode enters text in a color specific to one editor (though that color can change by editing session if editors are not logged in.)

  * The picture here shows what suggestion mode tends to look like, with a comment (asking for more information, and getting a response) and a suggestion (which also got a response, and was later "rejected" because it was literally just there to show what suggestions look like.



  

  * Parsing out what you see here:



Longer sections that need work are usually more appropriate as comments. Comments are a great way to ask for clarification or discuss larger issues, such as, "You put the punctuation outside the quotes here, but in the identical situation up there you put them on the inside, are you using British rules or American for this document?" 

  * To comment, highlight a section of text, and click the "comment" icon. This brings up a box in the margin.



 

It depends on how specific you are getting in your edits. Editors, in general, should _only_ use Editing mode if they are collaborating in more in-depth ways, and even then it can be helpful to have one person adding text in a different color so that people know who did what. Color won't carry over to AO3, and can be changed easily. Suggestions are more trackable, as they show up in the comment history. 

  * When you click on a suggestion in the text or in the margin, it will look like this: And you will be able to respond to the suggestion, click check mark to accept it, or X to remove it. Copying the text with suggestions unresolved  _will_ copy the suggestions and will likely create a mess.



 

 

  * The comment history floats and contains all comments and suggestions, even if resolved. A check mark appears next to resolved issues. This can be a good way to check on overridden comments to make sure they're resolved. (If you type over the entirety of a comment's yellow section, it will disappear from the side but not from comment history.



 

  * If something complex happens in your document that you don’t like, you can always go to “File” and “See Revision History” and see what changed, when. This is most useful if you're allowing anyone with the link to edit, and someone comes in and their cat walks on the keyboard, erasing your whole document and replacing it with keyboard smash. And many other situations. It's also a remedy vs. toddlers.



 

  * This can allow you to undo even large scale vandalism. You can copy and paste from the revision history, if you need to preserve existing edits but fix a long-past problem. Google remembers everything.  It can get slow if you go into detailed revisions on a huge document, but is a lifesaver if a disaster happens.



 

One of the biggest reasons that editors should use Suggestion mode vs. Editing mode is that recurring style/spelling/punctuation errors get really obvious. For example, if you change tenses frequently, and you have a beta reader who is constantly changing your “said” back to “says” or vice verse, you’re going to start paying attention to that when you’re writing. Punctuation rules that get missed frequently (such as forgetting to put commas in compound sentences) stand out when you’ve “accepted” that suggestion the twentieth time.  Globally accepting suggestions may seem faster, but you’ll learn more if you try to figure out why a suggestion is being made.

The choice of edit vs. suggest is in the hands of the editor, though of course a polite editor will abide by the preference of the author. But you, the document owner, can determine whether someone can edit or if they can only comment. I might set the public link to “only comment” if I’m dropping the doc link into a fandom’s chat for people to do a read-through rather than detailed nitpicking. Comment only is most useful for groups who haven’t learned how to use suggest yet. It is possible to have a dozen people editing a document at once, but the results can get hairy.

###  **Commenting vs. Chat**

  * So there is a chat function, which allows for real-time communication without leaving the document. The chat icon is right next to the little user icons up top, but only works if there are multiple users in the document. Using chat will log you in and remove anonymity.



 

Chat is not static and is not easily accessible once you’ve logged back out and back in again. Comments are static, like post-it-notes, and stay until resolved, but even then they stay in the comment log.

Use chat for conversation in the moment, use comments to talk about specific text points or for conversation when you’re not working at the same time as your beta/author. Clicking on a comment will take you to that point in your document. Handy!

When I beta read, I will often make a comment where I leave off, and then resolve it when I start editing again. Both editors and owners can resolve edits. I will often “resolve” something to check that it is correct, and then “undo” (ctrl-z) so that the author can see the edit being made.

###  **When Are You Finished Editing?**

Ideally your beta reader will sign off on the idea of the document being “done”. Their name is going in your author notes (Thanks to Aergie for helping with this one!) and so it is best to make sure they’re happy with how you’ve made your changes.

You do not have to accept every editing suggestion, but it’s polite to explain why a suggestion is not being accepted if they went through the effort of making it.

  * If your beta reader makes a suggestion, and you comment on it, and they’re happy with the comment, they should click “resolved” if they don’t have further comments, or respond if they have more input for you.
  * If they make a suggestion, and you follow it exactly, resolve the comment yourself.
  * If they make a suggestion that is general, and you edit the text substantially without deleting the comment (this happens if you replace the entire section the comment was in), put a note there that says, “Is this sufficient” or something to that effect. Let them resolve the comment if it is, or add more feedback if it is not.



For example, my beta reader may be passionate about always using Oxford commas. But I only use them when not using them changes the meaning of the sentence. This is because I got most of my professional editing experience in a magazine environment, where Oxford commas were not used. So my beta may suggest an Oxford comma, and I might explain that I will only use them when they affect meaning, and then they can resolve the comment if they’re satisfied with that, or I’ll resolve it a few days later when we’ve agreed to disagree. I almost always err on the side of making my beta readers happy, but sometimes they’re wrong. It happens. Sometimes I’m wrong, too.

Your document is done when there are no more unresolved suggestions and comments. Go ahead and resolve conversational comments when everyone has read them and/or they are no longer relevant, all comments are saved for posterity in the comments dialogue.

###  **A Note on Spell Checking (sorry, no pics)**

If you always work in one dialect (American English vs. UK English, for example), then the Google Docs spell checker is going to be okay. I GUESS.

But really, it’s terrible.

For anything longer than 5-10k, I will pull the whole thing out to Open Office because the spell check dictionaries are _so_ much more robust. So much. You can switch from American to UK and 95% of your Americanisms will just pop with red wiggles. It can’t catch weird idioms, but it will catch ise/ize or/our, l/ll and all that stuff and nonsense. If you’re like me and write in multiple fandoms (I went from the X-Files to Stargate to Doctor Who to Castle to Merlin to Check, Please, which means US, US, UK, US, UK, US, dictionary-wise) then this is a godsend. You can even set it to autocorrect you within the specific document. But it’s not as nice for beta reading. So the last thing I’ll do once all the comments are resolved is take the thing out to Open Office (this is freeware and not Microsoft Word) and use the spell checker there.

I paste back to Google Docs so my beta reader can give a once-over. If there’s nothing major (and sometimes italic/space issues creep in between Open Office and Google Docs) the next step is going to be bringing everything to AO3.

## Moving from Google Docs to AO3

    1. Highlight your whole document. The fast way to do this is “ctrl-A”.
    2. Now, copy. “ctrl-C” or right click and select “copy”.
    3. I’m assuming you know the basics of posting at AO3, so once you’ve got a new post set up, and filled in your title and tags and whatnot, you need to select the Rich Text button, instead of the default HTML. (This is super important for preserving italics. See below for a picture.)
    4. Click in the body and use “ctrl-V” or right click and select “paste”. (I work on PCs, this will be slightly different on a Mac, apple instead of ctrl or some such, and I don’t remember how to bring up the context menu.)
    5. Now, go through and use “ctrl-F” to find your scene break character, and replace all scene breaks with horizontal lines if you prefer, or center them if you are using emoticons.
    6. __Preview__ your document before you post! Read every word! You will find edits that need to be made. Go make them in the AO3 document. (Ironically, doing this for this very document showed an italic import error  _on this very line_ and I am not making that up. Totally screwed up my list, too.)
    7. At this point your text should be clean, correct, and you should be ready to apply work skins and work on other, more fancy stuff in the html if you really, really want to.
    8. Or you could just post it. That works, too.



  


	2. Chapter 2

Okay, so it’s been a while since I first wrote this tutorial for working in Google Docs with an AO3 endgame. And I thought it might be time for an update. Over a year and a couple hundred thousand words and god knows how many chapters later, I’ve learned quite a bit about staying organized through this process. 

Please bear with the informal tone and lack of pictures. If there’s anything you need a screenshot of, leave a comment or bug me on Tumblr and I’ll see what I can do. 

I might at some later date reorganize this and update the whole thing. For now, consider this an expansion pack.

###  **Considerations for posting**

First of all, it’s really important to know your fandom. If it’s only getting a few new fanfics per day, go ahead and edit scrupulously and re-read on AO3 before finalizing your posting. If you’re posting in a firehose fandom where there are often a dozen new fics in an hour? Lower your standards for initial posting (a little.)

This means that you need to set up everything but your final chapter breaks—all your editing, anything you can possibly do in Google docs—ahead of time. I strongly advise that you use your styles to change your font size and style significantly last thing before your last proof. 

####  **Working with styles**

First, let’s make things easy for you. Take this block of text:

* * *

Normal (The body of your text. Font doesn’t really matter, but  _ do _ set your line spacing in Google Docs to 1.5 and add a space  _ after _ paragraph.)

#  **Heading 1 <h1> Title**

##  **Heading 2 <h2> Subtitle**

###  **Heading 3 <h3> Chapter title**

####  **Heading 4 <h4> Scene title**

#####  **Heading 5 <h5> Small Subtitle**

######  **Heading 6 <h6> Footnote**

* * *

Copy everything between the lines from this AO3 document and paste it in your story’s Google Doc at the end (or even a blank one, it doesn’t matter.) Google Doc defaults to three header styles—doing this gives you the exact style names that Google Docs uses and how AO3 interprets them.

I don’t footnote fic this way, so I don’t always paste over all six heading variants. But pasting this block in the document will always give you the new header names to play with. Most people will only really ever use heading 4, with the occasional prologue title in heading 3, but H5 and H6 can be super useful for in-document navigation. I will often put wordcounts and important jump-to points that I don’t plan to carry into AO3 in those, so that my outline is more obvious and useful. They’re also extremely useful in outlining within the document. 

 

To see your new styles, look where it says “normal text” in Google Docs, and pull down the menu. You might have to zoom out to see the full list. 

Now, let’s use them! You learned in the first chapter how to set up your styles. As soon as you fix everything exactly how you want to work in Google Docs, and you’ve updated every style to match the selection that is set the way you like, please go to “Options” at the bottom of the style list, and pick “Save as my default styles.” This is important, as afterwards you’ll be able to pick “Use my default styles” in any existing document, and any new document will, at least for the first three headings, use your style preferences. 

Remember, while your heading tags and normal text and basic italics and bolds will carry over to the rich text editor, the accompanying font data or header styling does not carry over. This is both annoying and incredibly useful. It means that you can write your whole document in Comic Sans or Gothic and it won’t carry over to what your readers see. It also means that your carefully sculpted font designs and margins won’t show up either. 

But it also gives us a huge opportunity! See, we get used to seeing our words in the font we use in Google Doc. If we change that font significantly, say, shifting from Verdana (relatively wide) to Cambria (I’m looking at what Google Docs includes) or Consolas or even Comic Sans, our words are going to look really different, and our brains will pay better attention to them. Spelling errors, grammar errors and poor word choices are going to be a lot easier to see. 

This probably feels like a digression, but the point is actually that if you change your normal font before your last editing pass, you will create the same effect as posting! In other words, you will suddenly see your entire chapter in a new font, and you should be able to catch stuff you would otherwise catch five minutes after you posted.  In a rapidly moving fandom, skipping the preveiw-on-AO3 proof means you can get your new chapters up in seconds, by simply dropping it into the rich text editor, posting it, and then editing it to change your scene break markers after. Sure, this inflicts your tildes or bullets or whatever on the first readers, but they’re your first readers and they love you even if you aren’t using fancy lines between your scenes. 

Reminder: To change the normal font styling, highlight a section of paragraph text, change the font and then go up to the dropdown, click the arrow next to “Normal Text” and select “Update style to match.”  Your whole doc should shift (and shrink if you’ve gone from Verdana to Cambria) and you can then proof it.

Magically, to get it back to where it was? Just pick “Use my default styles” from the Options section on the style pulldown! 

But it doesn’t really matter. AO3 pays attention to the style tags, not the actual style unless you use skins, which is out of the scope of this tutorial. 

####  **Other Pre-posting Editing Tricks**

We covered beta readers, but keep in mind that it’s good to have as many eyes and techniques on a document as you can before posting. 

One of the most effective tricks I have for editing my original writing is to read it aloud. Dysfluencies jump off the page when you’re reading that way. I often read a scene sub-voce (under my breath) to check it if I’m not sure of the wording. This is a way to pick up missing or extra commas, to discover where you really need an em dash instead of commas, and to spot places where you need another speech tag or more descriptors. 

Anything you can do to change how your brain is interacting with the work can help. Text to speech add-ons exist. Hearing your story in a robot voice  _ really _ makes oddities stand out. (Also, hearing a droning robot voice read porn scenes should be an entire comedy subgenre. No, really.)

####  **Post-posting editing**

So here’s a list of things you need to double check after you post. Everyone. No matter how careful you are about pre-posting formating.

  * Scene breaks—swap tildes for whatever you’re normally using. In some docs I’ll use three bullets instead of tildes, and just center those, but AO3 sometimes picks them up as lists, so I need to watch that. If you don’t know how to fix that, use something else. The horizontal line is a good default if you don’t want to get creative. Center all if you’re formating that way.
  * Italics. Just skim through and make sure you didn’t miss any of the extra/missing space bugs. I still get these now and then, and they’re simply not catchable on proof in Google Docs.
  * Double line breaks. There should be a small gap between each paragraph. Not a big one. If there’s big ones, you probably didn’t set your line spacing correctly or you didn’t use paragraphs, just double line breaks. Go through and delete the extras. If it’s too many, consider pulling the document from Google Docs, taking it into Word or Openoffice, and searching for the double paragraphs/line breaks and killing them. Let me know if you need a tutorial for how to manage this. Open Office has a neat but not obvious way of handling this. To make it obvious in Google Docs, change your normal text style to stop having “line after paragraph”. If you still have spaces between paragraphs after you did that, replace those two line breaks with a paragraph break (see chapter 1) and then reassert your default styles. Re-paste back into AO3.
  * If you added html to your notes, summaries, etc… please check to make sure that AO3 isn’t inflating your note, summary, etc. every time you edit it. Sometimes it adds new breaks and paragraphs between every html bit in the note, sometimes it doesn’t. It is markedly less sophisticated about handling notes than it is about body text. This is fixable, but you have to fix it every time you edit the relevant bit.
  * Make sure any images actually ported over. You may have to place them after the fact—I haven’t tested this recently but I believe they will come over if you use “by URL” rather than any other method to embed the images.  If your document is image-heavy, you’ll probably need to preview it before posting. This is especially important if you’re using graphic dingbats for your scene breaks (see my Merlin fic.)




End file.
